Use explicit timer in unit test #1338
Conversation
… keyboard interrupts
|
FYI @nuno-faria and @kosiew |
|
@timsaucer I agree that it would be better to have something more deterministic. However, I think we still need a test to interrupt queries that continuously generate new batches, and therefore do not have the opportunity to check for interrupts (#1337 (comment)). For example, a really long generator ( |
…rrupt either collect or stream
This is a good point. I updated the unit test and combined them to check for fast/slow responses and either collect or stream. |
3 participants
Which issue does this PR close?
None but addresses the comment in #1337 (comment)
Rationale for this change
The current unit test for keyboard interrupts uses a long running query. This moves over to a simple query that uses a timer to make it run for longer than the keyboard interrupt checks. This matters because we are getting differences in how long it takes for the long running unit test to return based on upstream updates. The desired behavior is just that the query takes a long time, so we do not want to be dependent on performance improvements upstream.
What changes are included in this PR?
Adds a
slow_udfthat has a 2 second timeout in it.Uses this instead of a long running join.
Are there any user-facing changes?
No, only a test is updated.